i3 Call Handling: What Compliance Actually Requires

"i3 compliant" gets used to describe a lot of things that are not actually i3 compliant.

Every PSAP director has seen the term in an RFP response, a vendor slide deck, or a state grant application. It sounds like a fixed checkbox: either a system is i3 compliant or it isn't. In practice, i3 compliance is a layered set of technical behaviors, and a system can satisfy some of them while still routing calls the old way underneath.

This piece breaks down what NENA's i3 standard actually asks of the call handling function: how a call arrives, how location comes with it, what "additional data" means in practice, and where procurement language tends to get vague. None of this requires an engineering degree. It requires knowing which questions to ask.

The standard, briefly

NENA's i3 architecture is defined in NENA-STA-010, the i3 Standard for Next Generation 9-1-1. Version 3 of the standard was published in 2021 and received ANSI approval, with a series of lettered corrigenda since (NENA-STA-010.3a through .3f) correcting and clarifying details rather than changing the core architecture. NENA's i3 Architecture Working Group has been developing a further revision. Any vendor or agency citing "i3 compliance" should be able to say which version of NENA-STA-010 they mean, because the standard has moved since the original i3 concept papers circulated in the 2000s.

The standard defines a full NG911 architecture: the ESInet (the IP network connecting originating service providers to PSAPs), the NGCS (NG9-1-1 Core Services, the functional elements that route and deliver calls), and the i3 PSAP itself, defined as a PSAP capable of receiving IP-based signaling and media conformant to the standard. Call handling sits where that architecture becomes something a call taker actually experiences on screen.

How a native i3 call actually arrives

In a native i3 environment, a call reaches the PSAP as a SIP session, delivered through the Border Control Function (BCF) that sits at the network's edge. The BCF is the secure entry point into the ESInet: it handles firewalling, admission control, and in many designs anchors the session and media so the PSAP isn't directly exposed to the originating network. From there, the Emergency Services Routing Proxy and related core services route the call based on location, not on a fixed trunk group tied to a jurisdiction's old tandem switch.

That routing-by-location piece is what makes i3 fundamentally different from E911. A legacy system routes a call based on which circuit it arrived on. An i3 system routes based on where the caller actually is, using policy and location data evaluated at call setup. If a call handling system can't participate in SIP call delivery from a BCF and consume the location and routing data that comes with it, it is not handling i3 calls natively, regardless of what else is on the feature list.

Location by value versus location by reference

Location in i3 travels as a PIDF-LO, a structured location object that can describe a point, a shape, or a civic address with a defined confidence and method. Location arrives at the PSAP in one of two ways.

Location by value means the PIDF-LO itself is included directly in the call signaling. The call taker's system has the location the moment the call arrives, no additional lookup required.

Location by reference means the call signaling carries a Location URI instead of the object itself. The receiving system has to dereference that URI, essentially querying a location server, to retrieve the actual PIDF-LO. This is normal and expected in i3, particularly for mobile calls where location may update during the call. But it means the call handling system has to correctly perform that dereference step, quickly and reliably, or the call taker is staring at a call with no location while the dereference silently fails or times out.

A procurement question worth asking directly: does the system support both location by value and by reference, and what happens on the call taker's screen if a dereference fails or is delayed. A vendor who hasn't thought about that failure case hasn't built for real i3 traffic.

Native i3 versus the legacy network gateway

This is where "i3 compliant" gets slippery. NENA's architecture accounts for the fact that not every 911 call will originate on an all-IP network for a long time yet. The Legacy Network Gateway (LNG) is the defined functional element that interfaces a non-IP originating network with the NGCS, converting legacy signaling, and historically ALI (Automatic Location Identification) delivered through a database dip, into something the i3 core can route.

An LNG is a legitimate, standard part of the i3 architecture. It is not, however, the same thing as native i3 call delivery. A call that comes in through an LNG has been translated from a legacy format, and the location behind it may still be ALI-sourced rather than a PIDF-LO built natively. Both types of call can look similar on a call taker's screen if the call handling system does its job well, which is exactly why the distinction matters for procurement more than operations. Agencies buying a call handling platform should know whether they're being sold native i3 delivery, LNG-translated legacy traffic presented well, or, most likely for the next several years, both.

i3-ready, i3-capable, and what those terms are actually promising

None of "i3-ready," "i3-capable," or "i3 compliant" have a single fixed legal meaning, and vendors use them inconsistently. In practice they tend to map to different levels of commitment:

"i3-capable" usually means the system has the software architecture to process i3-style signaling and PIDF-LO location objects, but it may be running against an ESInet that hasn't been fully deployed yet.

"i3-ready" often means the vendor has done the engineering work but the agency's own network connectivity, whether that's ESInet buildout, BCF placement, or NGCS availability, is what's pending. The system could take native i3 traffic today if the surrounding network existed to deliver it.

Actually receiving native i3 calls means SIP calls are arriving through a live BCF, over a functioning ESInet, with PIDF-LO location attached, in production today, not in a lab or a future phase.

The honest answer from most vendors and agencies right now is somewhere in between, and that isn't a red flag by itself. Transitional states, running LNG-mediated legacy calls and native i3 traffic side by side during a phased ESInet rollout, are normal and expected under the i3 architecture. The red flag is a vendor who can't clearly explain which state an agency is actually in, or a contract that doesn't specify what happens to functionality as the agency moves from one state to the next.

Additional data, multimedia, and logging

i3 call handling extends past voice and location. NENA's Additional Data model defines structured data associated with the call, the caller, and the location, referenced or delivered alongside the call itself, that call takers can pull up: things like device information, medical or subscriber data a caller has opted into sharing, and building or premises information tied to the address. A call handling system's job is to retrieve and present that data without adding steps that slow a call taker down mid-call.

Multimedia support, primarily text-to-911 today, with photo, video, and other media types expected to expand as agencies and networks mature, is part of the same call handling layer. Text-to-911 sessions need the same routing and location discipline as voice calls, a meaningfully different problem than bolting an SMS inbox onto the phone system. Logging is easy to underweight during procurement: i3 environments generate call detail, location history, and additional data records that need to be retained and retrievable for quality assurance, incident review, and legal requests, and the call handling system is usually where that discipline either exists or doesn't.

Policy routing and where call handling fits

Routing decisions in i3, which PSAP a call goes to, whether it's redirected, how it's queued, are governed by policy stored and evaluated by core services like the Emergency Call Routing Function, not hardcoded into the call handling system itself. That separation is intentional: it's what allows an agency to change routing policy, add a backup PSAP, or handle an overflow scenario without reconfiguring every call taker workstation.

For call handling, this means the system needs to correctly receive whatever the routing layer decided, display why a call landed where it did when that information is available, and support the operational side of policy-driven routing, like accepting transferred or rerouted calls smoothly rather than treating them as anomalies.

Conformance testing: what actually exists

NENA maintains an NG9-1-1 Testing Program, which evaluates submissions against defined criteria using NENA's own standards and feeds into a broader NG9-1-1 Certification Program. Separately, NENA runs periodic Industry Collaboration Events, ICE, where vendors test i3 interoperability against each other and against the current standard in a shared environment; recent iterations have focused on i3 version 3 functionality, additional data, location, and end-to-end call handling. Agencies can reasonably ask whether a system has been through NENA's testing program or a recent ICE event, and ask to see the results, rather than accepting "i3 compliant" as a self-certified claim.

Common procurement misreads

Treating "i3 compliant" as binary. It isn't. Ask which layers, signaling, location, additional data, multimedia, are actually implemented and in what state, native or LNG-mediated.

Assuming a compliant call handling system means a compliant network. A platform can be fully capable of native i3 traffic and still receive nothing but LNG-translated calls because the agency's ESInet or service provider connection isn't there yet. That's a network issue, not a call handling defect, but the two need to be understood separately.

Skipping the failure-mode questions. What happens on screen when a dereference fails, additional data doesn't arrive, or a text session drops. Vendors demo the happy path; procurement should ask about the unhappy one.

Confusing a feature list with conformance. Multimedia support, mapping, and a modern interface are valuable, but they aren't evidence of conformance at the signaling and location layer.

Questions to ask any vendor

• Which version of NENA-STA-010 does your system conform to, and can you show documentation or test results supporting that claim?
• Does the system natively process SIP call delivery and PIDF-LO location objects from a BCF, or does it rely primarily on LNG-translated legacy traffic today?
• How does the system handle both location by value and location by reference, and what happens on the call taker's screen if a dereference fails or is slow?
• How is Additional Data for the call, caller, and location retrieved and displayed, and does that change under load or during a network transition?
• Has the system been evaluated through NENA's NG9-1-1 Testing Program or participated in a recent ICE interoperability event, and can you share the results?

Key Takeaways

• i3 compliance is layered, not binary: signaling, location, additional data, multimedia, and logging can each be at a different level of maturity in the same system.
• Native i3 call delivery means SIP signaling through a BCF with PIDF-LO location, in production. LNG-mediated legacy traffic is a normal, standard part of the architecture, not native i3, and both can coexist during a transition.
• Location by reference requires a working dereference step. Ask what happens when it fails.
• "i3-ready" and "i3-capable" are useful shorthand, but they aren't fixed technical terms. Ask vendors to define exactly what state their system and your network are in.
• NENA runs a defined NG9-1-1 Testing Program and periodic ICE interoperability events. Ask for real results rather than a self-certified label.

Most agencies are somewhere in the middle of this transition, running legacy and native i3 traffic side by side while ESInet buildout continues on its own timeline. That's expected. What matters is working with a call handling partner who can tell you exactly where you stand today and what changes as your network catches up. NGA's NEXiSConnect call handling system is built to work across that transition, handling native i3 and legacy-gateway traffic side by side while your agency migrates. If you want a straight answer about where your PSAP stands today, talk to our team.